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[Electronic Version 1.2.8] 

METHOD AND SYSTEM FOR DESCRIBING 
AND EXTRACTING APPLICATION 
INFORMATION 

Cross Reference to Related Applications 



This application is based on Provisional Application Serial No. 60/1 77,585, which was 
filed on January 23, 2000, and priority is claimed thereto. 

Background of Invention 



[0001] Field of the Invention. This invention relates to methods and systems for 

migrating software and/or software components from one computer system to another. 
More specifically, this invention relates to the transfer of computer application program 
settings and data files using one or more Application Information Files (AIF). 

[0002] Description of Related Art. A variety of techniques are well known in the art 

for transferring files and application programs from one computer system to another. 
Most common techniques include manually loading the files and programs via electro- 
magnetic media, such as computer disks, tape, and memory cartridges, or manually 
transferring the files and programs over a computer network. Such methods are 
generally time consuming and require that the application'^ specific settings be reset on 
each new computer installation. It is also known to use scripting files to describe and 
process application settings and files to help with the migration of applications from 
one personal computer (PC) to another. However, such techniques generally require 
that the user have extensive programming experience and knowledge in order to create 
a description of what and how to migrate an application. 

Summary of Invention 



[0003] It is desirable to provide a method and system which aids in the migration of 

computer files, including applications and data files, from one Personal Computer (PC) 
to one or more other PCs, without the requiring the user to manually move an 



application, its settings or files, where such are described in an Application Information 
File (AIF). 

[0004] Furthermore, it is desirable to provide a method and system for describing 

and translating the information in an AIF format, which provides a collection of tags that 
describe a computer application, its version, conversion settings, registry information 
and files. 

[0005] Therefore, it is the general object of this invention to provide a method and 

system for describing and translating the information in an AIF to simplify the migration 
of information from one PC to one or more other PCs. 

[0006] It is a further object of this invention to provide a method and system for 

describing and translating computer program files and information, which uses a 
familiar INI, file format. 

[0007] It is another object of this invention to provide a method and system for 

describing and translating computer program files as well as information which provides 
a simplified "tag= value"format. 

[0008] A further object of this invention is to provide a method and system for 

describing and translating computer program files and information that eases the 
creation and modification of program translation files. 

[0009] A still further object of this invention is to provide a method and system for 

describing and translating computer program files and information that permits the use 
of tools to automate the creation and modification of AlFs. 

[001 0] Another object of this invention is to provide a method and system for 

describing and translating computer program files and information wherein pre-existing 
robust Application Program Interfaces (APIs) can be used for writing data to an AIF using 
an INI file format. 

[001 1 ] These and other objects and advantages of this invention are achieved by the 

invention as described herein. 

Brief Description of Drawings 

[001 2] The accompanying drawings incorporated in and forming a part of the 

specification illustrate a preferred embodiment of this present invention. Some, 
although not all, alternative embodiments are described in the following description. In 
the drawings: 



[001 3] Figure 1 is a top-level system block diagram of the PC computer systems 

used in the preferred embodiment of this invention. 



[001 4] Figure 2 is a top-level flow chart showing the preferred method steps of this 

invention. 

[001 5] Figure 3 is a process flow chart showing the method steps whereby 

application data is transferred from an Installed file to a PC in the preferred embodiment 
of the invention. 

[001 6] Figure 4 is a process flow chart showing the preferred method steps of the 

transplant process of this invention. 

[001 7] Figure 5a is a process flow chart of the first section of the method steps of 

creating an Application Information File of the preferred embodiment of this invention. 

[001 8] Figure 5b is a process flow chart of the second section of the method steps 

of creating an Application Information File of the preferred embodiment of this 
invention. 

[001 9] Figure 6 is a process flow chart of the method steps of the process of 

showing the gathering of installed applications using Application Information Files, in 
this invention. 

[0020] Figure 7a is a process flow chart of the first section of the method steps of 

the Application data, gathered from an Application Information File, moving to an Install 
build file, of this invention. 

[0021] Figure 7b is a process flowchart of the second section of the method steps 

of the Application data, gathered from an Application Information File, moving to an 
Install build file, of this invention. 

[0022] Reference will now be made in detail to the present preferred embodiment of 

the invention, an example of which is illustrated in the accompanying drawings. 

Detailed Description 

[0023] This invention is a method and system, which provides an improved means 

for migrating applications, settings and data files between computer systems. It makes 
use of the Application Interface File (AIF) and describes, extracts and translates the 
information in an AIF to simplify the migration of information from one personal 
computer (PC) to another PC. 



[0024] An application program can be described by use of a defined set of tags. 

These tags can identify multiple versions of an application, how to convert settings 
across application versions, registry information, and files. A collection of these tags, 
grouped together into a file is known as an "Application Information File"(AIF). Using an 
AIF, this invention takes the described data and migrates an application along with its 
settings and data files to another computer. 

[0025] Preferably, the AIF of this invention uses INI file syntax with the following 

exception: duplicate value names are allowed within a section. INI file definitions are 
broken down into three parts: section name, value name, and value. An example of a 
typical INI definition may look like the following: 

[0026] [My Section] 

[0027] MyFirstValueName=Value 

[0028] MySecondValueName=Value 

[0029] [Another Section] 

[0030] MyFirstValueName=Value 

[0031] MySecondValueName=Value 

[0032] MyThirdValueName=Value 

[0033] 

[0034] All AlFs start with a section called Applications. Under that section a value 
name of EXE must exist. Its value is the name of the application's .exe file. For 
example: 

[0035] [Applications] 

[0036] EXE=Express.exe 

[0037] The EXE value listed must match the .exe filename listed under the registry 

key. for example: 

[0038] HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App 
Paths 

[0039] For use with Microsoft operating systems, Microsoft requires that all 

applications installed under Windows add the name of the application's executable to 
this registry key and include a default value of the full path to the executable. If this 



invention (the Wizard component) cannot find the executable listed in the AIF with the 
path defined in the registry, the application will not be displayed under the Application's 
tab. Another limitation of the AIF may occur during installation of the application. If the 
application settings and data files stored in a Personality Package do not match the 
version of the application on the destination PC, the registry settings and files may not 
be installed in the correct location or in the correct format for that version. 

[0040] After the Applications section of the AIF is a Version section providing 

information for each Version of the application. All versions of an application may be 
supported within the same AIF. Each Version section must provide a Description value 
name followed by a description of the application. For example: 

[0041] [4.0] 

[0042] Description=Altiris Express 4.0 
[0043] 

[0044] [4.1] 

[0045] Description=Altiris Express 4.1 
[0046] 

[0047] Using a version number of 0, allows a user to create default information 
about the application. For example: 

[0048] [0] 

[0049] Description=Altiris Express 

[0050] The remaining value names listed under the Version section follow the order 

Option, Flag, Base, and Values. These items can be repeated for each registry and file 
item to be associated with the application'^ version. 

[0051] The Option value can be one of two values TRUE or FALSE. The Option value 

lets the Wizard section of the invention know that the information that follows is 
optional. If the item is optional and the Wizard section is unable to collect the data, the 
setting will not be aborted. 

[0052] The Flag value can be one of four types: Registry, File, FileType, and API. 

The Registry Flag type is used to describe registry keys and values. The File Flag type is 
used to describe directories and files. The FileType is for a specific document type. 
FileType is used if the user wants to include a specific file or type of file, and yet the 



user does not know where it is located. Since FileType does not need a path, the Base 
value name is ignored. The API flag is used only internally. 

[0053] The Base value is used to describe the path to an item. The value provided 

for Base must correspond to the Flag type that is defined. For example, if a Flag value is 
Registry type, a Registry path must be specified. For a Flag of File type a directory path 
must be used. A path may include system environment variables, a program variable, or 
the contents of a registry value. Examples of system variables are: %windir%, 
%systemdir%, or %temp%. Program variables include: %MI_DESKTOP%, 
%M LSTARTM EN U%, %MI_SENDTO%, %MLFAVORITES%, %MI_WINSYSTEMDIR%, 
%MLAPPDATA%. To get the path from a registry value the syntax <%Reg:registry path- 
%> is used. 



[0054] The Values type is the specific item using the Base path. Wildcards may be 

used when specifying Values. Multiple values may also be specified by separating each 
value with a comma. For example: Values=filel .txt,file2.txt,file3.doc. 

[0055] The following are the examples showing the use of the Flag, Base, and 

Values: 

[0056] [4.0] 

[0057] Description=Altiris Express 4.0 

[0058] Flag=Registry 

[0059] Base=HKEY_CURRENT_USER\Software\Altiris\Altiris Express 

[0060] Value=*.* 

[0061] Flag-File 

[0062] Base=%windir% 

[0063] Value=express.ini 

[0064] Flag=File 

[0065] Base=<%REG:HKEY_CURRENT_USER\Software\Altiris\Altiris 
Express\directory%> 

[0066] Value=*.img 



[0067] 



[0068] Sub-items may be created for an application by creating a section name 

starting with the Version number, plus the name of the sub-item. Each sub-item may 
also use the Flag, Base, and Values definition. For example: 

[0069] [4.0 Rapidlnstall Packaged] 

[0070] Flag-File 

[0071] Base=<%REG:HKEY_CURRENT_USER\Software\Altiris\Altiris 

[0072] Express\directory%>\rips 
[0073] Value=*.exe 

[0074] For a sub-item to exist for all versions of the application the number "0"can 

be used as the version number before the name of the sub-item, for example: [0 Data 
Files]. 

[0075] Referring now to the figures and in particular to figure 1 . In the preferred 



embodiment of this invention a first computer system 1 00, which has a processing unit 
101 , with a processor, memory and a long term storage device, connected to an input 
device 102 and a display device is in communication 1 16 with one or more other 
destination computer systems 104, 108, 1 12. Each destination computer system also 
has a processing unit 105, 1 09, 1 13, with a processor, memory and a long term storage 
device, connected to an input device 1 06, 110, 114 and a display device 1 07, 111, 115. 
The communication channel 1 1 6 between the first computer system 1 00 and the other 
computer systems 1 04, 1 08, 1 1 2 is preferably a local area network, although alternative 
communication channels, including but not limited to a wide area network, a wireless 
network, the Internet or the like may be substituted without departing from the concept 
of this invention. The preferred computer systems 1 00, 1 04, 108, 112 are typically 
personal computers (PCs) although other computational devices can be substituted 
without departing from the concept of this invention. For the purposes of this 
disclosure, PC shall be interpreted to mean any computational device. 

[0076] Figure 2 shows the top-level steps of the preferred process of this invention. 

In general in its preferred embodiment, this invention consists of two key modules, the 
Console and the Self-exTracting Auto-Migrate Packages (STAMPs). The Console is run 
on the Source PC (the Source PC is the PC the user is migrating from). This executable 
program scans the drive(s) for the environment settings and files to be migrated and 
builds the STAMPs. The Console includes scan options for optimizing the disk scans 
and a filter for determining which settings and file types are included in the package for 
transfer. The Console also includes an edit function, which allows the user to add or 



delete files and settings from the STAMP before delivery to the Target PC (the Target PC, 
also referred to as the destination PC, is the PC the user is migrating to). 

[0077] The STAMPS are self-executing files that contain all of the files and settings 

to be migrated to the Target PC. These files contain all of the intelligence needed to 
write files to the appropriate destination and to make the appropriate registry changes. 
The STAMPS also allow the technician running the process on the Target PC to further 
filter the files and settings to be installed. 

[0078] The preferred migration process of this invention begins with deploying 201 

the new, or target PC. This step of the process assumes that the new PC has been 
installed with an operating system and applications and is configured for network 
connectivity. This step is preferably accomplished using a PC cloning product such as 
RapidDeploy™. 

[0079] Defaults are defined 202. This step establishes the file and setting defaults 

and includes which file extensions to extract and which directories to include and the 
like. 

[0080] Scan and Build is run 203. This step involves scanning the source PC and 

extracting from the source PC the files and settings. The STAMP file is also created 
during this step and is saved to a location accessible by the target PC. Typically and 
preferably the target PC is a file server. STAMP is then edited 204 by adding or removing 
files or registry settings. The resulting edited STAMP defines what will be transferred to 
the target (or new) PC. 

[0081] Options can be set 205 or adjusted at this point in the process. These 

options can include: unattended install, custom bitmap to use as a splash screen, STAMP 
description and instructions, and run STAMP password protection. 

[0082] STAMP is next run 206 on the new (or target) PC. This program can be 

executed either from the target PC or through some management or scheduling 
application, such as Microsoft SMS or Altiris RapidX. This program execution can be 
unattended or can be set to require a user prompt, where a user or technician can break 
in to make further custom changes to the migration. 

[0083] User changes 207 permit the user to view the contents of the STAMP and to 

exclude any files or settings from being installed, if the user breaks in. 

[0084] Installation 208 is the final step of the process where the files and registry 

settings are installed to the target PC. 

[0085] The reader should note that while this invention is designed generally to 

extract operating system settings, applications, settings and files, the present 



embodiment provides automatic migration capabilities for the following types of 
settings, applications and files. 

[0086] Currently supported settings include: accessibility, active desktop, colors, 

desktop icons, display properties, explorer settings, favorites, icon metrics, keyboard, 
mouse, pattern, power, printers, regional information screen, saver, send-to menu, 
shell, sound, start menu, task bar, wallpaper and window metrics. Currently supported 
applications include: Microsoft Office 97 Suite, Microsoft Internet Explorer, Microsoft 
Outlook and Netscape. 

[0087] Currently supported data files extractions include: (1) Automatic extraction, 

where files are automatically extracted based on file extension, full file name or 
directory location. Entire directories, or subdirectories, such as "MyFiles" may also be 
extracted automatically. (2) Pre-defined application types, which includes a library of 
file extensions for common software applications. The user has the option of including 
or excluding any known extension type. (3) Pre-defined folder types, which include a 
library of directory/folder names for common data directories (i.e., "MyFiles"). The user 
has the option of including or excluding any of these known directory types. (4) Other 
applications and folders are allowed by adding any user-defined file extension and 
include an option to use a wildcard for scanning and gathering files with any extensions. 
(5) Manual extraction capabilities provide the user with the ability to edit a STAMP by 
adding files, folders and registry settings manually to the package after the STAMP is 
created. 

[0088] The preferred embodiment of this invention includes a number of features to 

enhance the efficiency of the process of this invention, including: (1 ) Package 
compression depending on gathered file types, compression ranges from 30 to 70 
percent. (2) Cross-platform migration in the present embodiment, this process 
automatically converts operating system and connectivity settings between Windows 95, 
Windows 98 and NT 4. This allows users to migrate operating systems at the same time 
they migrate their PC and still maintain all user preferences and settings. (3) Drive 
exclusion provides the option of excluding any of the physical or logical drives on the 
source PC in the scan step. (4) Folder exclusion provides the option of excluding any 
folder/directory on any of the source PC drives in the scan step. (5) Self-extracting 
files provides self-extracting and fully self-contained STAMPs. No client agent is 
required to run the STAMP on the target PC. (6) Selectable file destination provides 
that STAMPs can be directed to any known storage device with a drive mapping, 
including hard disk drives, floppy disk drives, network server drives, Jazz™, Zip™, or CD 
ROM drives. (7) Disk space verification provides a check for available disk space on the 
target PC. This check is based on the extracted size, not the compressed package size. 
If there is not sufficient space for extraction, the program of this invention returns an 
error message. (8) Password protection provides password protection for STAMPs. 



Passwords may be defined as the STAMP is created or any time thereafter. The STAMP 
will prompt the user for the password prior to execution on the target PC. (9) Migration 
package description provides the capability of optionally including a description of up 
to 256 characters. This description will be displayed when the package (program) is 
executed. This text may describe the contents of the STAMP or provide instructions to 
the user/technician STAMPing the new PC. The user running the package process of 
this invention may choose at this point to continue or abort the migration. (1 0) 
Duplicate file options provides options for handling duplicate files, such as overwrite 
older, overwrite newer, always overwrite. This options are defined by the STAMP creator 
at the time the package is created. (1 1) Unattended migration provides the capability 
for supporting M quiet"or unattended installations. Command-line switches enable the 
STAMP to be run remotely through a scheduler or desktop management product without 
requiring a user to be present. (12) User-defined profiles permits the user to create 
and store profiles that will define which applications, folders, and files will be included 
in a STAMP. A dialog box within the Console module walks the user through the 
process of building the migration profile. This dialog box also allows the user to see 
which Profiles are already available and to enable the user to edit existing profiles. (1 3) 
Command-line mode provides the user with the ability to run STAMP from a command 
line or from a Windows "Run" command. This also enables the STAMPS to be run from 
within a scheduling or desktop administration application. Command line switches are 
available for (a) running in quiet mode (without user intervention); (b) calling a user- 
defined profile to use; and (c) defining a location to save the STAMP file. (1 4) Edit 
STAMP provides, through the Console module, the user capability of editing STAMPS, 
including adding and deleting files and making changes to the registry settings within 
the STAMP. This function allows users to further customize the migration. And (1 5) Log 
file with summary report provides a log file to track all changes made to the target PC 
and provides a report of what was not completed. Errors are also reported here. 

[0089] Figure 3 shows the detailed flow chart of the preferred process flow showing 

application data being transferred from an Install file to a PC. First, a Personality 
Package 301, containing the desired settings, preferences, applications and files, is 
loaded. The Package is executed 302 in the source PC processor. A desired file is 
retrieved 303. A valid path test 304 is made. If the path is not valid, the path is 
replaced 305 to fit the destination PC. Next, at test 306 is made to determine if the file 
is a shell link. If the file is a shell link, it is added 307 to the shell link list. Next, the file 
is copied 308. A test 309 is made to determine whether there are more files to migrate. 
If there are more files to migrate the process returns to step 303, getting a file. 
Otherwise, the Registry is retrieved 310. A test 31 1 next is made to determine if the 
Value path is valid. If the Value path is not valid the path is replaced 31 2 to fit the 
destination or target PC. Next, the Registry Item is copied 31 3. A test 314 is made to 
determine if there are more Registry Items. If more Registry Items remain, the process 
returns to the Get Registry step 310. Otherwise, the application version specifics are 



retrieved 31 5. A test 31 6 is then made to determine if the destination or target 
application versions match. If they do not match, an error is written 31 8. Next, the 
shell links are updated 31 7 using the shell link list. Then the migration process ends 
319. 

[0090] Figure 4 is a process flow chart showing the preferred method steps of the 

transplant process of this invention. A number of applications programs 401 a-n are 
provided to the system of this invention. These application programs 401 a-n, in the 
present preferred embodiment can be any Windows based computer application 
program, such as, but not limited to Microsoft Word. The application programs 401 a-n 
have extracted an application description 402a-n, which is loaded in the PC Transplant 
Application Information File (AIF) 402. Each AIF 402 provides the required information 
to the PC Transplant Wizard process 403. The present preferred PC Transplant Wizard 
process 403 comprises the steps of presenting 404 application descriptions to the user, 
then selecting 405 applications and finally gathering 406 the application data. The 
result of the PC Transplant Wizard 403 is provided to the PC Transplant Personality 
Package 407 which performs the function of transplanting 408 application data to the 
PC. 

[0091] Figure 5a is a process flow chart of the first section of the method steps of 

creating an Application Information File of the preferred embodiment of this invention. 
The process shown in figures 5a and 5b are the process of creating an Application 
Information File (AIF) in the present preferred embodiment of the invention. The 
Application of interest is provided 501. The provided Application is researched 502 to 
determine the description of the Application. A new AIF file is created 503. An 
Application section is created 504. A new value name under the Application called EXE 
is defined 505. The defined EXE value is set 506 equal to the Application'^ executable 
file name. Next, an Application version section is created 507 using, in the present 
preferred embodiment, the syntax: <MajorxMinor>. A new value name under version 
called Description is defined 508. The Description is set 509 equal to the Application 
version description. A test 51 0 is then made to determine if any registry keys or values 
are present. If there are no registry keys or values, then process moves to step 514, 
shown on figure 5b. If there are registry keys or values, then the flag = registry value is 
added 51 1 to the version section. Next, the Base=<Registry Key Path> is added 512. 
And, finally the Value=<Value Name> is added 513. 

[0092] Figure 5b is a process flow chart of the second section of the method steps 

of creating an Application Information File of the preferred embodiment of this 
invention. If the test 51 0 of whether any registry or key values are present is no, then a 
test 514 is made to determine if there are any files. If there are files, then Flag^File 
Vale is added 51 5 to the version section. The Base=<Directory Path> is added 516 and 
the Value=<File Name> is added 517. If there are not files, then a test 51 8 is made to 



determine if there are any file types. If there are file types, the Flag=Flag Type Value is 
added 519 to the version section and the Value=<File Name> is added 520. If there are 
no file types, at test 521 is made to determine if there are any version sub-items. If 
there are any version sub-times, then an Application Version Section is created 522 
using the syntax: <MajorxMinorxDescription>, after which the process returns to 
step 510, described above. If there are no version sub-items, then a test 523 is made 
to determine if there are any common version sub-items. If there are any common 
version sub-items, an Application Version Section using syntax: 0 <Description> is 
created 524. Following the creation 524 of this Application Version Section the process 
returns to step 510 as described above. If there are no common version sub-items then 
a test 525 is made to determine if there are any other application versions, if there are 
other application versions, then the process returns to step 507, described above. If 
there are no other Application versions then this section of the process ends. 

[0093] Figure 6 is a process flow chart of the method steps of the process of 

showing the gathering of installed applications using Application Information Files, in 
this invention. After starting this process begins with a search 601 for an AIF in the 
current directory. A test 602 is made to determine if an AIF is found. If no AIF is found, 
the Applications and their sub-items are displayed 61 3 using App map, and the process 
ends. If an AIF is found, in the test 602, an AIF is opened 603, the Application 
Executable is gotten 604. The AIF Application is validated 605 with the current installed 
version. Then a test 606 is made to determine if AIF data is available for the installed 
version. If no AIF data is available then the next AIF is gotten 607 and the process 
returns to the test 602 for determining if an AIF is found. If AIF data for the installed 
version is available then the description is gotten 608 and stored in the App map. 
Application files are gotten 609 and stored in App map and then Application registries 
are gotten 610 and stored in App map. Next, a test 61 1 is made to determine if there 
are any Application sub-times for versions. If there are no Application sub-items for 
versions, the next AIF is gotten 607. If there are Application sub-items for versions, 
then the next sub-item is gotten 612 and the process returns to step 608, as described 
above. 

[0094] Figure 7a is a process flow chart of the first section of the method steps of 

the Application data, gathered from an Application Information File, moving to an Install 
build file, of this invention. This process starts and a new install file is created 701. 
Next, install options are initialized 702. The selected Application is gotten 703. The 
App EXE name and version are stored 704. An Application item is gotten 705. Next, a 
test 706 is made to determine if an item is a file entity. If the item is not a file entity, 
then a test 71 0 is made to determine if an item is a registry entity. If an item is a file 
entity, the file is looked up 707. Another test 708 is made to determine if a file is 
found. If no file is found, then the process proceeds to test 71 0. If a file is found, the 
file is stored 709 in the install file. If the item is not a registry entity, the process 



proceeds to step 714 of figure 7b. If the item is a registry entity, then the registry item 
is gotten 71 1 , after which a test 71 2 is made to determine if a registry item is found. If 
no registry item is found, then the process proceeds to step 71 4 of figure 7b. If a 
registry item is found, it is stored 71 3 in an install file and the process proceeds to step 
714 of figure 7b. 

[0095] Figure 7b is a process flow chart of the second section of the method steps 

of the Application data, gathered from an Application Information File, moving to an 
Install build file, of this invention. Step 71 4 is a test to determine if there are any more 
items. If there are more items, then the process returns to step 705 described above 
with respect to figure 7a, If there are no further items, then a test 71 5 is made to 
determine if there are any more selected Applications. If there are more selected 
Applications, then the process returns to step 703 described above in the description of 
figure 7a. If there are no more selected Applications, a test 71 6 is made to determine of 
there are any Application file types. If there are no Application file types this part of the 
process ends. If there are Application file types then a search 71 7 is made for selected 
drives for file types. After which, a test 71 8 is made to determine if a file is found 
matching the file type. If such a file is found then, the file is stored 71 9 in the install file 
and the process returns to step 71 7, described above. If no such file is found, a test 
720 is made to determine if the drive searches are complete. If the searches are 
complete then this part of the process of this invention ends. If the drive searches are 
not complete, the process returns to step 71 7 described above. 

[0096] It is to be understood that the above described and referenced embodiments 

and examples are merely illustrative of numerous and varied other embodiments and 
applications which may constitute applications of the principles of the invention. These 
example embodiments are not intended to be exhaustive or to limit the invention to the 
precise form, connection or choice of components, computer language or modules 
disclosed herein as the present preferred embodiments. Obvious modifications or 
variations are possible and foreseeable in light of the above teachings. These 
embodiments of the invention were chosen and described to provide the best 
illustration of the principles of the invention and its practical application to thereby 
enable one of ordinary skill in the art to make and use the invention, without undue 
experimentation. Other embodiments may be readily devised by those skilled in the art 
without departing from the spirit or scope of this invention and it is our intent that they 
be deemed to be within the scope of this invention, as determined by the appended 
claims when they are interpreted in accordance with the breadth to which they are fairly, 
legally and equitably entitled. 



Claims 



